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(54) Control message transmission in packet switching 

(57) Message packets pass control information between a central telecommunications station and a 
controller for one or more telecommunications stations, eg in a wireless/cellular system. A packet includes a 
header including a packet start pattern and a message size identifier for individually setting a message size for 
respective packets; a variable number of message records, each having a size relating to the message size 
selected for the packet' and a packet terminator including a unique packet end pattern invalid as an initial bit 
sequence for a message record. The tracking of transmissions is facilitated by the use of cyclical sequence 
numbers and an arrangement whereby up to a predetermined number of messages may be sent without an 
acknowledgement. 
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CONTROL MESSAGE TRANSMISSION 
IN TELECOMMUNICATIONS SYSTEMS 

The present invention relates to control message transmission in 
telecommunications systems. Particular aspects of the invention relate 
to a message packet transmitter and receiver, a message packet, a 
central telecommunications station and a controller for one or more 
telecommunications system(s). 

In a telecommunications system where a central telecommunications 
station support-: a plurality of subscribers and a controller is 
provided for controlling one or more such central telecommunications 
stations, it is necessary to pass control and other messages between 
the controller and the central telecommunications station. The 
messages should be handled in a reliable and efficient manner. It 
should also be possible to detect messages which are lost and to re- 
send those messages. 

In accordance with a first aspect of the invention, there is 
provided a message packet transmitter for generating message packets 
for passing control information between a central telecommunications 
station and a controller for one or more telecommunications stations, 
wherein the message packet transmitter generates packets of information 
comprising: 

a packet header including a packet start pattern and a message 

size iden.ti.fier for.indivadAi,all3^..setxinf=- a me:SS^,.^e.^..sd,ze. for r;es.Di?.a!t:J. \'e 
packets; 

a variable number of message records, each having a size 
determined by the- message size selected for the packet; and 

a packet terminator including a packet end pattern invalid as an 
initial bit sequence f or a message record. 

The use of a packet terminator including a packet end pattern 
avoids the need to identify the total length of packets by indicating 
the number of bytes or the number of messages of a given size, for 
example. It provides a method of readily identifying the end of a 
packet and provides freedom as to the length of a packet. Also, by 
constraining all messages in the message packet to be of the same 
length, this avoids the need to indicate separately the length of each 
message record and/or to use a message record terminator for each 
message record. As a result of the combination of these features, a 




very low packet overhead is needed so that a high message data rate can 
be achieved with a very small overhead for packet control information. 

Preferably* the message size for the message packets is 
selectable from a predetermined plurality of fixed sizes {e.g., four). 
5 This also reduces the packet overhead as a low number of bits (e.g., 
two) are needed to define the message record sizes. 

In one embodiment of the invention, the message records in the 
message packet comprise a fixed length message record header and a 
message field for a message, the message field having a size 
10 corresponding to the message size. In alternative embodiments, 
however, the message records could have a size corresponding to the 
message size. 

Preferably, a message record is provided with a message control 
field including a message type identifer identifying the message record 
15 as a command message or a report message and/or an element address to 
which the message record refers. The message record can also be 
provided with a message identifier field for defining a function code 
for the message record and/or with a task identifier for associating 
message records. 

20 A message packet sequence identifier can be added to each packet 

to facilitate the detection of errors in transmission and recovery from 
such errors. The message packet sequence identifier is preferably a 
nu;j)ber whi.ch Ss increme.D.ted in.odul:0-nt,. .wbe.re .n Is >a. Mh^le •mmb.er j^rnaater 
than 0, for successive packets. 

25 In accordance with another aspect of the invention, there is 

prcvided a message packet for passing control information between a 
central telecommunications station and a controller for one or more 
telecommunications stations, wherein the message packet comprises: 

a packet header including a packet start pattern and a message 

30 size identifier for individually setting a message size for respective 
packets; 

a variable number of message records, each having a size 
determined by the message size selected for the packet; and 

a packet terminator including a packet end pattern invalid as an 
35 initial bit sequence f or a message record. 

In accordance with a further aspect of the invention, there is 
provided a message packet receiver for receiving message packets as 
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defined above or for receiving message packets from a message packet 
transmitter as defined above, wherein the message packet receiver 
comprises means responsive to the start pattern to identify a message 
packet header, means for extracting the message record size identifier 
5 for the message packet header and for receiving and routing the message 
records until the end pattern is recognised. 

Preferably, a message packet receiver, on successful receipt of 
a message packet, returns to .the message packet generator an 
acknowledgement including the packet sequence number of the message 

10 packet successfully received. This enables transmission errors to be 
readily identified. 

In accordance with a further aspect of the invention, there is 
provided a message packet receiver for a message packet system for 
passing control information between a central telecommunications 

15 station and a controller for one or more telecommunications stations in 
which a message packet transmitter is arranged to allocate message 
packet sequence identifiers to successive message packets with the 
message packet sequence identifier being changed in accordance with a 
predetermined sequence for successive message packets, the message 

20 packet receiver being arranged to track the message packet sequence 
identifiers for successive packets and to return an acknowledgement 
including the message packet sequence identifier for the last 
s u c c es sfxx I Xy . recei ve.d .mes s?ci^e -.p^^ eke t .when^. nke uD.T?i3i5i?,r(fLrjn .i.ntf^ d ;CJT.f?oNVf?-n>':tfT .^cVj- 
broken or after a predetermined number of successfully received 

25 messages since the last acknowledgement was sent, the predetermined 
number defining a sequence window. The use of a sequence number window 
enables messages to be sent in an efficient manner without having to 
wait for an acknowledgement of each message before sending the next 
message. In a real-time system such as a telecommunications system, it 

30 is important that messages can be routed rapidly without delays caused, 
for example, by a requirement to await an acknowledgement. 

Preferably, the message packet receiver is responsive to receipt 
of a message packet with a message sequence identifier for a previous 
sequence window for which an acknowledgement has already been sent to 

35 retransmit the acknowledgement for the previous window. 

Preferably, also, the message packet receiver is responsive to 
receipt of a message packet having a message packet sequence identifier 
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^ 

which is out of sequence but does not relate to the previous sequence 
window or to a next sequence window to discard the message packet. 

In accordance with another aspect of the invention, there is 
provided a message packet transmitter for passing control information 
5 between a central telecommunications station and a controller for one 
or more telecommunications stations, the message packet transmitter 
being arranged to allocate message packet sequence identifiers to 
successive message packets, with the message packet sequence identifier 
being changed in accordance with a predetermined sequence for 

10 successive message packets, and to transmit up to a predetermined 
number of message packets to a message packet receiver, the 
predetermined number defining a sequence window, the message packet 
transmitter being responsive to the receipt of an acknowledgement 
including a message sequence identifier associated with message packet 

15 within the sequence window other that the last message packet of the 
window and to the absence of receipt of an acknowledgement from the 
message packet receiver including the sequence identifier for the last 
message packet of the window within a predetermined period following 
the transmission of the last of message packet of the sequence window 

20 and to re- transmit the message packets subsequent to the message packet 
associated with message sequence identifier in the received 
acknowledgement . 

P,re-rf?-.nab,.l V , x^b^. -.-n,es.sage.,4n4?x',ke.?: vX.rjimt-tV^iiT..ze.r -is. :r,esjPo.as j.v» .jpo, the 
absence of any acknowledgement from the message packet receiver within 

25 a predetermined period following the transmission of the last message 
packet of the sequence window to retransmit all the message packets of 
the sJequence window. 

The invention also provides a message packet system comprising a 
message packet receiver and a message packet transmitter as defined 

30 above . 

The invention further provides a controller for one or more 
central telecommunications stations, the controller comprising a 
message packet transmitter as defined above, for transmitting control 
information to a central telecommunications station, and/or a message 
35 packet receiver as defined above, for receiving control information 
from a central telecommunications station. 

The invention also provides a central telecommunications station 
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comprising a message packet receiver as defined above, for receiving 
control information from a controller for one or more central 
telecommunications stations, and/or a message packet transmitter as 
defined above, for transmitting control information to a controller for 
one or more central telecommunications stations. 

The invention further includes a telecommunications system 
comprising a controller and one or more central telecommunications 
stations as defined above. 

An embodiment of the invention will be described hereinafter, by 
way of example only, with reference to the accompanying drawings in 
which like reference signs are used for like features and in which: 

Figure 1 is a schematic overview of an example of a wireless 
telecommunications system in which an example of the present invention 
is included; 

^5 Figure 2 is a schematic illustration of an example of a 

subscriber terminal of the telecommunications system of Figure 1 ; 

Figure 3 is a schematic illustration of an example of a central 
terminal of the telecommunications system of Figure 1; 

Figure 3A is a schematic illustration of a modem shelf of a 
central terminal of the telecommunications system of Figure 1; 

Figure ^ is an illustration of an example of a frequency plan for 
the telecommunications system of Figure i; 

Figures 5A and 5B are .schejnatJx ^^dia^rrams JA2j:xs±.x:j^xjj^ .jp^^^^ir^J.^ 
configurations for cells for the telecommunications system of Figure 1; 
25 Figure 6 is a schematic diagram illustrating aspects of a code 

division multiplex system for the telecommunications system of Figure 
1 ; 

Figure 7 is a schematic diagram illustrating signal transmission 
processing stages for the telecommunications system of Figure 1; 

Figure 8 is a schematic diagram illustrating signal reception 
processing stages for the telecommunications system of Figure 1; 

Figure 9 is a schematic diagram illustrating in more detail the 
configuration of the modem shelf of Figure 3A; 

Figure 10 is a schematic block diagram illustrating control 
35 protocols for the telecommunication system of Figure 1; 

Figure 11 is a schematic block diagram illustrating message 
handling modules for passing control messages between a site controller 



20 
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or element manager and a modem shelf controller in the 
telecommunication system of Figure 1; 

Figure 12 is a schematic block diagram illustrating message 
packet construction for control messages in Figure 11; 
5 Figure 13 is a message accumulation state diagram for a message 

handling module of Figure 11; 

Figure Ik is a schematic diagram illustrating the different 
protocol levels for, connection of a master to a slave for communication 
between a shelf controller and slave elements; 
10 Figure 15 is a schematic diagram illustrating the establishment 

of connection of a master to a slave for communication between a shelf 
controller and slave elements; 

Figure l6 is a schematic diagram illustrating the sending of a 
message from the shelf controller to a slave element; 
15 Figure 17 is a schematic block diagram illustrating event 

handling by a shelf controller; 

Figure 18 is a schematic block diagram illustrating control 
structures of a control terminal site controller; 

Figure 19 is a schematic block diagram illustrating a 
20 configuration data base structure of a control terminal site 
controller; and 

Figure 20 is a schematic representation of the connection of a 

Figure 1 is a schematic overview of an example of a wireless 
25 telecommunications system. The telecommunications system includes one 
or more service areas 12. 1^; and l6, each of which is served by a 
respective central terminal (CT) 10 which establishes a radio link with 
subscriber terminals (ST) 20 within the area concerned. The area which 
is covered by a central terminal 10 can vary. For example, in a rural 
30 area with a low density of subscribers, a service area 12 could cover 
an area with a radius of 15-20Km. A service area 14 in an urban 
environment where is there is a high density of subscriber terminals 20 
might only cover an area with a radius of the order of 100m. In a 
suburban area with an intermediate density of subscriber terminals, a 
35 service area l6 might coven an area with a radius of the order of IKm. 
It will be appreciated that the area covered by a particular central 
terminal 10 can be chosen to suit the local requirements of expected or 
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actual subscriber density, local geographic considerations » etc, and is 
not limited to the examples illustrated in Figure 1. Moreover, the 
coverage need not be, cind typically will not be circular in extent due 
to antenna design considerations, geographical factors, buildings and 
so on, which will affect the distribution of transmitted signals. 

The central terminals 10 for respective service areas 12. l^ , 16 
can be connected to each other by means of links 13, 15 and 17 ' which 
interface, for example, with a public switched telephone network (PSTN) 
l8. The links can include conventional telecommunications technology 
using copper wires, optical fibres, satellites, microwaves, etc. 

The wireless telecommunications system of Figure 1 is based on 
providing fixed microwave links between subscriber terminals 20 at 
fixed locations within a service area (e.g.. 12. l6) and the 

central terminal 10 for that service area. In a preferred embodiment 
15 each subscriber terminal 20 is provided with a permanent fixed access 
link to its central terminal 10. However, in alternative embodiments 
demand-based access could be provided, so that the number of 
subscribers which can be serviced exceeds the number of 
telecommunications links which can currently be active. 
20 Figure 2 illustrates an example of a configuration for a 

subscriber terminal 20 for the telecommunications system of Figure 1. 
Figure 2 includes a schematic representation of customer premises 22. 

The customer radio unit 2U includes a flat panel antenna or the like 
^5 23. The customer radio unit is mounted at a location on the 

customer's premises, or on a mast, etc., and in an orientation such 
that the flat panel antenna 23 within the customer radio unit 2^ faces 
in the direction 26 of the central terminal 10 for the service area in 
which the customer radio unit 2^ is located. 

'^^e customer radio unit 2k is connected via a drop line 28 to a 
power supply unit (PSU) 30 within the customer's premises. The power 
supply unit 30 is connected to the local power supply for providing 
power to the customer radio unit 24 and a network terminal unit (NTU) 
32. The customer radio unit 24 is also connected to via the power 
35 supply unit 30 to the network terminal unit 32. which in turn is 
connected to telecommunications equipment in the customer's premises, 
for example to one or more telephones 3^ . facsimile machines 36 and 
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computers 38- The telecommunications equipment is represented as being 
within a single customer's premises. However, this need not be the 
case, as the subscriber terminal 20 preferably supports either a single 
or a dual line, so that two subscriber lines could be supported by a 
single subscriber terminal 20. The subscriber terminal 20 can also be 
arranged to support analogue and digital telecommunications, for 
example analogue communications at 16, 32 or 64kbits/sec or digital 
communications in accordance with the ISDN BRA standard. 

Figure 3 is a schematic illustration of an example of a central 
terminal of the telecommunications system of Figure 1. The common 
equipment rack comprises a number of equipment shelves kZ, ^^ , 46, 
including a RF Combiner and power amp shelf (RFC) 42, a Power Supply 
shelf (PS) k^ and a number of fin this example four) Modem Shelves (MS) 
46. The RF combiner shelf 42 allows the four modem shelves 46 to 
operate in parallel. It combines and amplifies the power of four 
transmit signals, each from a respective one of the four modem shelves, 
and amplifies and splits received signals four way so that separate 
signals may be passed to the respective modem shelves. The p^wer 
supply shelf 44 provides a connection to the local power supply and 
fusing for the various components in the common equipment rack 40. A 
bidirectional connection extends between the RF combiner shelf 42 and 
the main central terminal antenna 52, typically an omnidirectional 
^janten.na.. „.m.oiJ-n.ted, .on -a ..■c.er^X.na.'l .re.r:CT7..1r?,nl ..urras.t .:7^.0.. 
This example of a central terminal 10 is connected via a point- 
to-point microwave link to a location where an interface to the public 
switched telephone network I8, shown schematically in Figure 1, is 
made. As mentioned above, other types of connections (e.g.. copper 
wires or optical fibres) can be used to link the central terminal 10 to 
the public switched telephone network I8. In this example the modem 
shelves are connected via lines 47 to a microwave terminal (MT) 48. A 
microwave link 49 extends from the microwave terminal 48 to a point-to- 
point microwave antenna 5^ mounted on the mast 50 for a host connection 
to the public switched telephone network I8. 

A personal computer, workstation or the like can be provided as 
a site controller (SC) 56 for supporting the central terminal 10. The 
site controller 56 can be connected to each modem shelf of the central 
terminal 10 via. for example. RS232 connections 55- The site 




9 

controller 56 can then provide support functions such as the 
localisation of faults, alarms and status and the configuring of the 
central terminal 10. A site controller 56 will typically support a 
single central terminal 10, although a plurality of site controllers 56 
5 could be networked for supporting a plurality of central terminals 10. 

As an alternative to the RS232 connections 55, which extend to a 
site controller 56, data connections such as an X.25 links 57 (shown 
with dashed lines in Figure 3) could instead be provided from a pad 228 
to a switching node 60 of an element manager (EM) 58. An element 

10 manager 58 can support a number of distributed central terminals 10 
connected by respective connections to the switching node 60. The 
element manager 58 enables a potentially large number (e.g. , up to, or 
more than 1000) of central terminals 10 to be integrated into a 
management network. The element manager 58 is based around a powerful 

15 workstation 62 and can include a number of computer terminals 6^ for 
network engineers and control personnel. 

Figure 3A illustrates various parts of a modem shelf U6. A 
transmit/receive RF unit (RFU - for example implemented on a card in 
the modem shelf) 66 generates the modulated transmit RF signals at 

20 medium power levels and recovers and amplifies the baseband. RF signals 
for the subscriber terminals. The RF unit 66 is connected to an 
analogue card (AN) 68 which performs A-D/D-A conversions, baseband 
f.il tarip.R:.,aoi:l .the ..vector. fSMmn>.arS^cTn.^.of J:5..;r„rj?in,T.e,:'jttt^^ 

modem cards (MCs) 70. The analogue unit 68 is connected to a number of 
25 (typically 1-8) modem cards 70. The modem cards perform the baseband 
signal processing of the transmit and receive signals to/from the 
subscriber terminals 20. This includes 1/2 rate convolution coding and 
X 16 spreading with CDMA codes on the transmit signals, and 
synchronisation recovery, de-spreading and error correction on the 
30 receive signals. Each modem card 70 in the present example has two 
modems, each modem supporting one subscriber link (or two lines) to a 
subscriber terminal 20. Thus, with two modems per card and 8 modems 
per modem shelf, each modem shelf could support I6 possible subscriber 
links. However, in order to incorporate redundancy so that a modem may 
35 be substituted in a subscriber link when a fault occurs, only up to 15 
subscriber links are preferably supported by a single modem shelf ^6. 
The l6th modem is then used as a spare which can be switched in if a 
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failure of one of the other 15 modems occurs. The modem cards 70 are 
connected to the tributary unit (TU) 7^ which terminates the connection 
to the host public switched telephone network l8 (e.g., via one of the 
lines 47) and handles the signalling of telephony information to, for 
5 example, up to 15 subscriber terminals (each via a respective one of 15 
of the l6 modems). 

The wireless telecommunications between a central terminal 10 and 
the subscriber terminals 20 could operate on various frequencies. 
Figure 4 illustrates one possible example of the frequencies which 

10 could be used. In the present example, the wireless telecommunication 
system is intended to operate in the 1.5"2.5GHz Band. In particular 
the present example is intended to operate in the Band defined by ITU-R 
(CCIR) Recommendation F.701 ( 2025-21 lOMHz , 2200-2290MHz) . Figure 4 
illustrates the frequencies used for the uplink from the subscriber 

15 terminals 20 to the central terminal 10 and for the downlink from the 
central terminal 10 to the subscriber terminals 20. It will be noted 
that 12 uplink and 12 downlink radio channels of 3-5MH2 each are 
provided centred about 2155MHz, The spacing between the receive and 
transmit channels exceeds the required minimum spacing of 70MHz . 

20 In the present example, as mentioned above, each modem shelf will 

support 1 frequency channel (i.e. one uplink frequency plus the 
corresponding downlink frequency). Up to 15 subscriber links may be 

in the present embodiment, each central terminal 10 can support 60 

25 links, or 120 lines. 

Typically, the radio traffic from a particular central terminal 
10 will extend into the area covered by a neighbouring central terminal 
10. To avoid, or at least to reduce interference problems caused by 
adjoining areas, only a limited number of the available frequencies 

30 will be used by any given central terminal 10. 

Figure 5-^ illustrates one cellular type arrangement of the 
frequencies to mitigate interference problems between adjacent central 
terminals 10. In the arrangement illustrated in Figure 5A, the hatch 
lines for the cells 76 illustrate a frequency set (FS) for the cells. 

35 By selecting three frequency sets (e.g., where: FSl = Fl . FU . F7 . FIO; 
FS2 = F2, F5, F8, Fll; FS3 = F3 , F6, F9 , F12), and arranging that 
immediately adjacent cells do not use the same frequency set (see, for 
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example, the arrangement shown in Figure 5A) , it is possible to provide 
an array of fixed assignment omnidirectional cells where interference 
between nearby cells cem be avoided. The transmitter power of each 
central terminal 10 is set such that transmissions do not extend as far 
5 as the nearest cell which is using the same frequency set. Thus each 
central terminal 10 can use the four frequency pairs (for the uplink 
and downlink » respectively) within its cell, each modem shelf in the 
central terminal 10 being associated with a respective RF channel 
(channel frequency pair). 

10 With each modem shelf supporting one channel frequency (with 15 

subscriber links per channel frequency) and four modem shelves, each 
central terminal 10 will support 60 subscriber links (i.e., 120 lines). 
The 10 cell arrangement in Figure 5A can therefore support up to 600 
ISDN links or 1200 analogue lines, for example. Figure 5B illustrates 

15 a cellular type arrangement employing sectored cells to mitigate 
problems between adjacent central terminals 10. As with Figure 5A, the 
different type of hatch lines in Figure 5B illustrate different 
frequency sets. As in Figure 5A, Figure 5B represents three frequency 
sets (e.g,, where: FSl = Fl . F^ . F7 , FIO; FS2 = F2, F5, F8, Fll; FS3 

20, = F3. F6, F9« F12) . However, in Figure 5B the cells are sectored by 
using a sectored central terminal (SCT) 13 which includes three central 
terminals 10, one for each sector SI, S2 and S3, with the transmissions 
for each of the three .cen.tral terminals 10 being directed to xhe 
appropriate sector among SI, S2 and S3. This enables the number of 

25 subscribers per cell to be increased three fold, while still providing 
permanent fixed access for each subscriber terminal 20. 

A seven cell repeat pattern is used such that for a cell 
operating on a given frequency, all six adjacent cells operating on the 
same frequency are allowed unique PN codes. This prevents adjacent 

30 cells from inadvertently decoding data. 

As mentioned above, each channel frequency can support 15 
subscriber links. In this example, this is achieved using by 
multiplexing signals using a Code Division Multiplexed Access (CDMA) 
technique. Figure 6 gives a schematic overview of CDMA encoding and 

35 decoding. 

In order to encode a CDMA signal, base band signals, for example 
the user signals for each respective subscriber link, are encoded at 
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80-80N into a l60ksymbols/sec baseband signal where each symbol 
represents 2 data bits (see. for example the signal represented at 8l). 
This signal is then spread by a factor of l6 using a respective Walsh 
pseudo random noise (PN) code spreading function 82-82N to generate 
5 signals at an effective chip rate of 2 . 56Msymbols/sec in 3-5MHz. The 
signals for respective subscriber links are then combined and converted 
to radio frequency (RF) to give multiple user channel signals {e,g., 
85) for transmission from the transmitting antenna 86. 

During transmission, a transmitted signal will be subjected to 

10 interference sources 88, including external interference 89 and 
interference from other channels 90. Accordingly, by the time the CDMA 
signal is received at the receiving antenna 91. the multiple user 
channel signals may be distorted as is represented at 93- 

In order to decode the signals for a given subscriber link from 

15 the received multiple user channel, a Walsh correlator 94-94N uses the 
same pseudo random noise (PN) code that was used for the encoding for 
each subscriber link to extract a signal (e.g, as represented at 95) 
for the respective received baseband signal 96-96N. It will be noted 
that the received signal will include some residual noise. However. 

20 unwanted noise can be removed using a low pass filter. 

The key to CDMA is the application of orthogonal codes that allow 
the multiple user signals to be transmitted and received on the same 

spreading of the signals using PN codes as the number of user signals 
25 increases, Rademacher-Walsh codes are used to encode the spread user 
signals. Once the bit stream is orthogonally isolated using the Walsh 
codes, the signals for respective subscriber links do not interfere 
with each other. 

Walsh codes are a mathematical set of sequences that have the 
30 function of "orthonormality" . In other words, if any Walsh code is 
multiplied by any other Walsh code, the results are zero. 

The following example will illustrate this using a four bit 
spreading code for ease of illustration, rather than the I6 bit 
spreading code preferred in practice. 

35 
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Figure 7 is a schematic diagram illustrating signal transmission 
processing stages as configured in a subscriber terminal 20 in the 

15 telecommunications system of Figure 1. The central terminal is also 
configured to perform equivalent signal transmission processing. In 
Figure 7» an analogue signal from one of a pair of telephones is passed 
via a two-wire interface 102 to a hybrid audio processing circuit 104 
and then via a codec 106 to produce a digital signal into which an 

20 overhead channel including control information is inserted at 108, The 
resulting signal is processed by a convolutional encoder 110 before 
being passed to a spreader ll6 to which the Radermacher-Walsh and PN 
codes are appli.ed by a W r.a6B ,i?:eneramr JJ2 P.h: .QiOi^ 
respectively. The resulting signals are passed via a digital to 

25 analogue converter 118. The digital to analogue converter llS shapes 
the digital samples into an analogue waveform and provides a stage of 
baseband power control. The signals are then passed to a low pass 
filter 120 to be modulated in a modulator 122. The modulated signal 
from the modulator 122 is mixed with a signal generated by a voltage 

30 controlled oscillator 126 which is responsive to a synthesizer l60- 
The output of the mixer 128 is then amplified in a low noise amplifier 
130 before being passed via a band pass filter 132, The output of the 
band pass filter 132 is further amplified in a further low noise 
amplifier 13^, before being passed to power control circuitry 136. The 

35 output of the power control circuitry is further amplified in a further 
low noise amplifier 138 before being passed via a further band pass 
filter mo and transmitted from the transmission antenna mz. 
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Figure 8 is a schematic diagram illustrating the equivalent 
signal reception processing stages as configured in a subscriber 
terminal 20 in the telecommunications system of Figure 1. The central 
terminal is also configured to perform equivalent signal reception 
5 processing. In Figure 8, signals received at a receiving antenna 15O 
are passed via a band pass filter 152 before being amplified in a low 
noise amplifier 154. The output of the amplifier 154 is then passed 
via a further band pass filter 156 before being further amplified by a 
further low noise amplifier 158. The output of the amplifier 158 is 

10 then passed to a mixer 164 where it is mixed with a signal generated 
by a voltage controlled oscillator l62 which is responsive to a 
synthesizer I6O. The output of the mixer l64 is then passed via the 
de-modulator 166 and a low pass filter I68 before being passed to an 
analogue to digital converter 17O. The digital output of the A/D 

15 converter 17O is then passed to a correlator I78. to which the same 
Radermacher-Walsh and PN codes used during transmission are applied by 
a RW code generator 172 (corresponding to the RW code generator 112) 
and a PN code generator 174 (corresponding to PN code generator ll4), 
respectively. The output of the correlator is applied to a Viterbi 

20 decoder I8O. The output of the Viterbi decoder I80 is then passed to 
an overhead extractor l82 for extracting the overhead channel 
information. The output of the overhead extractor l82 is then passed 

where the resulting analogue signals are passed to a selected telephone 
25 192. 

Figure 9 is a schematic diagram illustrating in more detail the 
configuration of one of the modern shelves 46. The shelf controller 72 
manages the operation of the whole of the modem shelf and its daughter 
network sub-elements (NSEs). The shelf controller (SC) 72 is provided 

30 with a RS232 serial port 59 for connection to a site controller or to 
a pad for connection to a data network such as an X.25 data network. 
The shelf controller communicates control and data information via a 
backplane asynchronous bus 212 directly with the analog-ae card (AN) 68, 
the tributary unit card (TU) 74 and the modem cards (MC) 70. Other 

35 network sub-elements are connected via the modem cards. In a fully 
populated rack there will be four shelf controllers, one on each modem 
shelf. These four shelf controllers are configured to share the 
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control of network service elements on other cards in the rack. The 
network service elements on the RF combiner shelf 42 are connected to 
the shelf controller backplane bus on each of the modem shelves. The 
shelf controller includes a master communications interface .73 for 
5 performing the communications functions mentioned above and other 
control functions. Each of the tributary card 7^ , the analogue card 68 
and each modem card 70 includes a respective slave communications 
interface 7^ . 69 and 71. which manages the communications with the 
shelf controller 72. The RF card 66 is controlled from the analogue 

10 card 68, which is configured to provide the necessary control functions 
via the control path 222. 

Also shown in Figure 9 are the signal paths from an interface to 
the public switched telephone network (e.g via lines ^l in Figure 3) 
and the interface to an RF combiner shelf 42. 

15 The tributary unit ^^ terminates the connection to the host 

public switched telephone network and handles the processing of 
telephony information for up to 15 subscriber terminals (up to 30 
calls). The tributary unit 74 is 'on-line' in that it directly 
processes calls. The tributary unit 74 is also connected to a 2Mb/s 

20 time-multiplexed (timeslot) transmit bus 2l4 and 2Mb/s time-multiplexed 
(timeslot) receive bus 2l6 for transmit and receive calls, 
respectively. 

The modems ,( .1 - 15,) ...on .the.v^modBJtTi cands JQ .pe,rfann basehvaF?.d. ,s±f2jnal 
processing of the transmit and receive signals including the 

25 convolution coding and spreading functions on the transmit signals, and 
the synchronisation recovery. de-spreading and error correction 
functions on the receive signals, as described earlier. Each modem is 
connected to the tributary unit 74 via the transmit and receive buses 
214 and 2l6, and to the analogue card 68 via a dedicated connection 220 

30 to one of a number of ports on the analogue card and via a digital CDMA 
RCV bus 218. Each of these dedicated connections includes multiplexed 
I. Q and control transmit paths. 

The analogue card 68 performs A-D/D-A conversions, baseband 
filtering and vector summation of the 15 transmit signals from the 

35 modem cards. The analogue card 68 also scales the transmit signal 
power level according to high or low power levels. It is connected to 
the modem cards via the dedicated connections 220 and the digital CDMA 
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RCV bus 218. 

The RF card 66 generates the modulated transmit RF signals (at 
medium power level) and recovers and amplifies the baseband RF signal 
from the subscriber terminals 20. The RF card is * on-line' in that it 
5 passes up to 30 calls simultaneously via the 15 available links, all on 
the same RF carrier. The RF card is connected to the analogue card via 
transmit and receive paths 226 and 224 , respectively. The RF card is 
also connected to power amplifiers of the RF combiner shelf on tae 
transmit side and to a low noise amplifier on the receive side. The 

10 power amplifiers (not shown) in the RF combiner shelf amplify the 
medium power output of the RF card 66 to an appropriate transmit power 
plus an amount to cover losses during signal combination and in the 
antenna feeder cable for the transmit signal. The low noise amplifier 
(not shown) is a low signal amplifier for overcoming losses in the 

15 antenna feeder etc. for the receive signal. The transmit carrier 
modulation is performed by the RF card 66 using an 'IQ modulator' at 
intermediate frequency and a single conversion to RF. The receive 
output of the RF card is at baseband in 'IQ' format as per the transmit 
input to the RF card. 

20 Figure 10 is a schematic block diagram illustrating an example of 

various control protocols used for the transmission of control 
information between different parts of an example of a 
xeJ.,ecomnumi.c3.?:jir?n.s .,sy.rv;t,em J.n v^^?.cco.^d^^iT:lce. .Kl.th ,bhf? ...InwenX-iinn^. . >Lr: . sibni.^li^ 
be noted that Figure 10 is directed to the control signal paths » and 

25 accordingly, the telephone call signal paths are not included. Many of 
the features of Figure 10 have already been described above » and in 
this case the same reference numerals are used as before. Accordingly, 
these features will not be described again in detail. 

A first protocol, called the Sub-system Management Processor 

30 (SMP) protocol, is used for communications between the shelf controller 
72 and a site controller 56, or element manager 58, via lines 59 and 
55. or 59 and 57, respectively. The first protocol is a balanced 
protocol with either party to a communication being able to initiate an 
exchange of information. The first protocol and the types of message 

35 which can be sent will be described in more detail below. As mentioned 
above, the shelf controller 72 is provided with an RS232 serial output 
for connection to a site controller 56. Accordingly, if a connection 
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is provided instead to an element controller 62, represented 
schematically by the switch 227 » a pad 228 for connection to an X.25 
line, or the like, is used to convert between RS232 format and X.25 
format . 

A second protocol, called the Radio Link Termination (RLT) 
protocol, is used for passing control and data information via the 
control 212 and data 213 buses on the modem shelf. In addition, it 
should be noted that the same protocol is valid on the radio link 226 
between the antenna 52 of the central terminal and the subscriber 
terminal (s) 20. 

The second protocol is an unbalanced protocol with the 
microprocessor 73 in the shelf controller 72 acting as a busmaster (M) 
and the microcontrollers 69, 71 and 75 on the analogue card 68, the 
modem cards 70 and the tributary unit Ik acting as slaves. 

The first protocol and the message structure will now be 
described in more detail. 

The first protocol is used for information exchange in both 
directions between the site controller 56, or element controller 58 if 
connected instead, and a selected modem shelf controller 73. In the 
following description of the first protocol, the term management 
processor will be used for ease of reference to be either a site 
controller or an element manager, as the first message protocol is the 
same whether a site .control ler 56 Is .c.ozmBoh^d .x.o .a .s.bel.r .x.CiT^.tXval J;er 
via an RS232 link 55, or an element manager 58 is connected to a shelf 
controller via an X.25 link 57 and the pad, 228. 

On initially establishing a connection between the management 
processor and the shelf controller, and preferably also at intervals 
during operation, an authentication process is undertaken. The 
authentication process is advantageous to stop potential intruders from 
extracting, distorting and corrupting the information within the 
telecommunications system. The details of the authentication process 
do not form part of the instant invention and will therefore not be 
described herein. However, it will be appreciated that any number of 
conventional authentication processes could be employed using the 
identities (e.g.. serial numbers) of various components, transaction 
numbers, etc. 

When it is desired to establish a communication, a call set up 



i8 



sequence is employed. An example of a call set up procedure where an 
management processor (MP) initiates a call to a shelf controller (SC) 
includes : 



MP Action/Response 

Set up call using SC address — > 

Detect call setup < — 

Check received MP address 

Drop call if incorrect 

Send 'authentication' message 

Check validation result and <-- 
SC information. Drop call 
if information check is false 



SC Action/Response 
Wait 

Set up call using MP address 

Validate 'authentication' message 
Send 'authentication reply* with SC 
data and result of validation 
Drop call if validation false 



The first protocol is message based. Individual messages tend to 
be relatively short and are blocked for transmission within message 
packets. Each such packet, which is variable in length, can carry one 
or more messages, all of which must be the same size. The maximum 
packet size, excluding the packet header, is chosen in the present 
example to be 260 bytes. With the 260 byte maximum packet length, the 
pa.cke.t jnay ^cont.ain ,e.ixher .one ,23'6 ^hv^te <.;a.f?:.*?:s^.?jejn... . • .thd.ritvae.n .l£ .th-^-'trr 
messages, thirty-two 4 byte messages or fifty-two 1 byte messages. 



A packet consists of the following fields: 



SOP Start of Packet 3 bytes 

CTRL Control Byte 1 byte 

Messages variable 

HOP End of Packet 3 bytes 

CRC Cyclic Redundancy Check 2 bytes 



The purpose of the fields SOP, CTRL, EOP and CRC will now be 
explained in more detail. 
SOP 

This defines the start of a packet and is represented by 3 unique 
bytes, 'AA' hex followed by 'EE' hex followed by * AA ' hex (i.e.. in 
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binary 1010 1010 1110 1110 1010 1010). It will be noted that for each 
nibble the MSB is 1 and the LSB is 0. 
CRTL 

This defines the controls for the packet. The first two bits 
5 define the message size for the packet. The four possible sizes are as 
f ollows : 

Type 1 '0 0' 1 byte 

Type 2 »0 1* 4 bytes 

10 Type 3 '10* l6 bytes 

Type k '11* 256 bytes 



The third bit defines the packet direction: '0' is from the 
management processor to the shelf controller and '1* from the shelf 

15 controller to the management processor. 

The last five bits are used to identify a packet sequence number 
(PSN). The packet sequence number represents a window used for flow 
control. The sender may send a number of packets, up to the window 
size (or a smaller number {e.g.. five) if this is pre-arranged before 

20 a packet exchange) , before receiving a packet acknowledgement from the 
receiver. The acknowledgement advances the window and allows the 
sender to overwrite the packets acknowledged. 

A packet (PSN=n) received out of .seauance, .or ^..wlt.h..an ..e.rnor after 
application of the CRC, leads to an acknowledgement for packet sequence 

25 number (n-1). The acknowledgement packet indicates whether a CRC error 
was found. Ail packets after the acknowledged one then have to be 
retransmitted to avoid the complication of selective re-transmission. 

From the values O...31 which can be accommodated within the five 
bit sequence number, the value 0 is reserved for sequence number re- 

30 synchronisation (to be described later) so that the normal sequence 
numbers are 1. 2. 3,.. 30, 31, 1. 2.,.. 

A maximum number of outstanding acknowledgement packets is 
defined as a number which must be less than half the number of valid 
sequence numbers. For purposes of illustration only, in examples to be" 

35 described below, a window size of five is assumed. The receiver is 
arranged to recognise the concept of the 'previous' window (the last 
window length's worth of message packets from the current expected 
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sequence number) and the 'next' window (the next window length's worth 
of message packets). 

Acknowledgement packets do not have a sequence number as such, 
rather the sequence number field will always be set at zero, and are 
always sent singly (i.e., they are not packaged with other messages). 
Acknowledgement packets are not acknowledged themselves and are not 
subject to the window limit, they can be sent at any time. 

The immediate re- transmission of packets may be requested by 
setting the top bit of the packet acknowledgement data byte. This 
causes any remaining un- acknowledged packets to be immediately re- 
transmitted rather than waiting for a time-out. The meaning of the 
rest of the acknowledgement remains unchanged. 

After start-up and sometimes during operation, it is necessary to 
re-synchronise the sequence numbers between the sender and the 
receiver. The special sequence number 0 is used for this purpose. The 
reception of the 0 sequence number resets the expected sequence number 
variable of the receiver. After the reset, it is no longer valid for 
packets from the previous window to be received until after the first 
acknowledgement has been sent. 

The two message flow directions are completely independent. The 
state of the message flow from the management processor to the shelf 
controller is not allowed to affect the flow of messages in the other 
direction. ,.and vice versa. 

In the following, a number of examples of packet flow between a 
sender and receiver are illustrated. In the examples, a window size of 
five is chosen. This means that up to five packets may be sent without 
an acknowledgement. The receiver need not wait until five packets have 
been received, but can send an acknowledgement when it is convenient. 
In the packet flow examples set out below, the sender is shown in the 
left column, the receiver in the right column. The arrows indicate the 
direction of packet flow. 

Example 1 . 



Normal state (acknowledgement after five packets). 



6 



8 
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9 "> 

10 — > 

<~ 10 

5 Example 2 

A packet (not the first after an acknowledgement) is lost. The 
receiver acknowledges up to the packet before the missing one and 
packets after the missing one are discarded. The sender re-sends the 
remaining packets after a timeout. The receiver can then send the 
10 acknowledgement on recognising the missing packet. 

6 -> 

7 — > 

3 

15 9 — > ignored 

10 — > ignored 

<— 7 

Timeout. . . 

8 -> 
20 9 — > 

10 

10 



Example 3 

^5 The first packet after an acknowledgement is lost. In this case 

the receiver does not send an acknowledgement but waits for the packets 
to be re-sent in due course. 



30 7 --> ignored 

8 ignored 

9 ignored 

10 --> ignored 
Timeout . . . 

35 6 -> 
7 - --> 
8 
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9 — > 

10 — > 

<— 10 

5 Elxample A 

An acknowledgement is lost. In this case the receiver will get 
packets from the previous window which it had tried to acknowledge. 
The response is to resend the previous acknowledgement as soon as a 
packet from the previous window is received. It is possible that a 
10 plurality of acknowledgements will be sent as transmission is not 
instantaneous. The sender accounts for this and discards 

acknowledgements for packets for which acknowledgements have already 
been received. 

15 6 --> 

7 --> 

8 "> 

9 "> 

10 --> 

20 • i- 10 

Timeout . . . 

6 • — > 

ID 

25 Elxample 5 

A spurious packet is received, which is neither from the previous 
nor the next window. The receiver ignores the packet. It may be due 
to corruption, in which case the packet will be treated as lost and one 
of the above scenarios will come into play. It may also be due to a 
30 loss of synchronisation. If this is the case, the sender will detect 
this due to lack of acknowledgements and will then retransmit all the 
outstanding packets starting with the special sequence number 0, 

7 --> 

35 8 . 

9 — > 

10 --> 
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<-- 10 
5 — > ignore 

EOF 

5 This defines the end of the packet and is represented by three 

unique bytes, 'EE' hex followed by *AA' hex followed by *EE' hex (i.e., 
in binary 1110 1110 1010 1010 1110 1110). The initial combination of 
bytes of the end of packet sequence should start with a byte sequence 
which is invalid for data in the message fields. It will be noted that 
10 for each nibble the MSB is 1 and the L5B is 0. 

The use of the end of packet field avoids the need to identify 
the total length of packets by indicating the number of bytes or the 
number of messages of a given size, for example. 

CRC 

^5 This is used to detect errors in both the packet header and the 

messages. A CRC error leads to the transmission of an acknowledgement 
for the last packet correctly received. 

The structure of the message records will now be described in 
more detail. Each message record consists of a four byte header 
20 followed by the message data field. 

The message header consists of: a message control byte; a sub- 
address byte; a message ID byte; and a task reference number byte. 

One bit in the message cantnoJ .,byte t^h« ..lyLSSJ,..def^lr^.e'^, n-:bf^ 
type of message (e.g, '1* for command. '0' for report) and is used in 
25 combination with the message ID to define the message processing 
required. The remaining 7 bits of the message control byte define an 
element address to which the message refers (e.g. the address of a 
modem to which a message is directed). 

The sub-address byte is a sub-address field within the element 
30' addressed by the message control byte. 

The message ID byte defines the identity (equivalent to a command 
code) of the message. 

The transaction identifier byte can be used to match up commands 
to a shelf controller with replies from it. 
35 For any message capable of exceeding 256 bytes, the first byte of 

the data field contains a message sequence number (MSN) which is set to 
zero for each new message sent and is incremented for each 256-byte 
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fragment (i.e. packet sending that message). The first data byte also 
contains a 'more* bit to indicate that the current package is not the 
last one for that message. The bit is set to zero for the last message 
fragment sent. If such a message is received out of sequence, the 
5 receiver sends a packet acknowledgement for the last packet correctly 
received. The sender will then resend all packets following the one 
which has been acknowledged. 

All reports relating to specific events will be sent with an 
event sequence number (ESN) to distinguish them from other events. An 

10 event clear message can be used to identify an event to be cleared. 

The length of the data field for a message is given in the packet 
control byte. All messages in a packet have the same length. In the 
present example the data field can be 1, ^, l6 or 156 bytes in length. 

Figure 11 is a schematic block diagram illustrating the 

15 architecture of the message handling modules which are provided in the 
management processor and the shelf controller for constructing, sending 
and receiving messages. 

The message handling modules are described with reference to 
Figure 11 for the situation where they are located in a shelf 

20 controller, which is communicating with an element controller via an 
X . 28 format line to a pad and from there to the element controller via 
an X.25 format line. The same structure is used where there is an 
,RS232 connection (i.e... .an .X . 28 Lovsnat line) . dlre.ctO.y .to a s.ite 
controller. Similarly, the same basic structure is employed in a site 

25 controller or element controller at the other end of the line. The 
processes performed in the message handling modules can be implemented 
on suitable processing hardware including, as appropriate, one or more 
microprocessors and/or special purpose hardware. 

The message hcindling modules, and consequently the protocol can 

30 be thought of as having a plurality of different layers. The layers A- 
E illustrated in Figure 11 form part of a layer 2 protocol. 

In Figure II, layer E is responsible for transmitting and 

receiving strings of characters representing messages to and from the 
transmission link. The transmitter is responsible for duplicating 

35 characters in message packets. The receiver contains a state machine 
that assembles incoming characters into messages. This layer performs 
particular functions, which are; initialise the layer, transmit a 
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message, receive a message and accumulate messages. The last of these 
functions is responsible for accumulating bytes into messages. It 
handles both communications with the pad and command messages as well 
as message packets. Bytes that cannot be fitted into a message are 
discarded. 

Figure 13 is a state diagram illustrating the process of 
accumulating bytes into packets in layer E. 

In state 262 the process idles waiting for an input byte. 

In state 262 » if a received byte is a printable character, then 
control passes via 280 to state 290 where the process waits for a 
service signal. 

In state 290, if a printable byte is received, then this is 
stored and control loops at 291. In state 290, if another control 
character is received, then all bytes are discarded and control passes 
via 292 to state 262. In state 291, if a carriage return or line feed 
byte is received, then this is discarded and a pad message is processed 
and control passes via 293 to state 262. 

In state 262, if a received byte is a start of packet byte, then 
the byte is stored and control passes via 26^ to state 265. In state 
262, if a received byte is anything other than a start of packet byte 
or a printable character, the byte is discarded and control loops at 
263. 

In state 265. if a first header by.te is receded x±ien ..the ..byte 
is stored and control passes via 266 to state 268. In state 265, if any 
other byte is received, the all bytes are discarded and control passes 
via 267 back to state 262. 

In state 268, if a second header byte is received, then the byte 
is stored and control passes via 269 to state 271. In state 268, if 
any other byte is received, the all bytes are discarded and control 
passes via 270 back to state 262. 

In state 271. any byte received is stored, a message length is 
calculated, a new message condition is started and control passes to 
state 273- 

In state 273^ if a received byte does not complete a record, the 
byte is stored and control lops at 27^. In state 273, if a received 
byte completes a record but no end of packet is received, then a new 
message record is started and control loops at 275. In state 273, if 
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a received byte completes a record and an end of packet byte is 
received, then the byte is stored and control passes via 276 to state 
277. In state 277. if" a received byte does not complete a packet 
trailer, then the byte is stored and control loops at 278. If a 
received byte does complete a packet trailer, then the byte is stored 
and control passes via 279 to state 262. This completes the 
description of the state diagram of Figure 13- 

Returning to Figure 11, layer D 242 is a layer which provides 
message composition/decomposition for messages in accordance with the 
X.28 format. Message packets are passed through this layer unchanged. 
This layer performs the following functions to provide encoding and 
decoding of pad to the X.28 standard. The functions are: send a wake- 
up string to the pad; send a message packet to the pad; decode an 
incoming pad message; send initialisation messages to the pad; send a 
call message to the pad; send a clear message to the pad; send a 
parameter request message to the pad to probe whether it is still 
there; and receive an incoming message packet. 

Layer C 2U0 provides for call control. This layer maintains the 
connection with the transmission link (e.g.. the pad 228) and makes 
network calls when message packet output is required. It also is 
responsible for breaking calls when they idle for too long. This layer 
performs the following functions to maintain the serial connection to 
the pad .a,nd to mr3j.nt.a±n „tb^ call .throMlT^b the. X...u23. i?ietw.ork., .narr^l.y: 
initialise the layer; perform background processing; respond to a call 
from layer D when a disconnect is detected; respond to a call by layer 
D when a connect is detected; respond to a call by layer D when a pad 
prompt is received; instruct the layer to create a connection with the 
management processor; send an application packet; respond to a call by 
layer D when communication with the pad is lost; receive an incoming 
message packet; and respond to a call by layer D to indicate receipt of 
the pad probe response. 

The background processing function has the following tasks: 

- If the connection with the pad is down, a wake-up string is sent to 
the pad once per second until a pad prompt is received, this then 
triggers the initialisation of the pad. 

- If a call to the management processor is required and one is not 
currently in progress, a call is placed with the pad. 
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- Every twenty seconds, if the pad is recorded as being connected, a 
probe message is sent to the pad including a request for the state of 
a pad parameter. If a response to this is not received within a ten 
second time-out period, the pad is assumed to be disconnected. 
5 Layer B 236 provides functions for performing the exchange of 

authentication messages between the shelf controller and the management 
processor whenever a call is connected. The functions are: initialise 
the layer; request the creation of an authenticated link with the 
management processor; respond to call by layer C when a call is 
10 connected; respond to a call by layer 3 when an authentication message 
is received; respond to a call by layer C when a call is disconnected; 
send a message packet; and receive a message packet. 

The level 2 composer 238 provides encoding functions for 
authentication messages. The functions are: encode a shelf controller 
15 ID (SC ID) message; encode an 'authentication reply* message; and 
encode a 'packet acknowledgement' message. 

Layer A 23^ provides programming interface functions to layer 3 
of the protocol stack. The functions are: initialise the layer; return 
TRUE if the layer can accept an output message; send an application 
20 packet; respond to call by layer B when a link is established; and 
receive a message packet. 

The packet constructor 232 collects messages into packets for 
transmission and handles the re- transmission of pa£:kets case .of 

failure. 

-5 The record composers 23O are a series of modules which provide a 

layer between the encoded form of a message and the information which 
the message represents. These record composers actually form part of 
other subsystems that generate SMP messages and are only shown here to 
put the message handling modules into context. 

30 The message class identifier 2^6 takes incoming packets and 

breaks them into their component messages (message records). Each 
message (message record) is then passed to an appropriate decoder 
module. This module is also arranged to track sequence numbers of 
received packets and generate appropriate acknowledgements. To do this 

35 it maintains in storage a list of received sequence numbers and the 
current window boundaries. Logic (typically implemented in software) 
then tracks the sequence numbers and interprets the sequences as 
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described above to determine when to send an acknowledgement and what 
to send. 

The packet, constructor and the message class identifier form part 
of the layer 3 protocol. 
5 Figure 12 illustrates the packet constructor module 232 in more 

detail. The data records for messages are assembled into packets by 
this packet constructor module. Incoming records at 248 are sorted 
into one of the four packet construction buffers 250 according to the 
data field size. Separate buffers 252, 25^* 256 and 258 are provided 

10 for 1 byte, 4 byte, 16 byte and 156 byte data fields, respectively. 
When a buffer is full or in response to a predetermined transmit 
instruction, for example after a predetermined time has elapsed, the 
content of a buffer is sent over the transmission link and also copied 
to slot in a retry buffer 260 corresponding to the packet sequence 

15 number. There is one slot in the retry buffer for each sequence 
number. The retry buffer entry is cleared if an acknowledgement is 
received. If a retry instruction is received, the failed packet is re- 
transmitted directly from the retry buffer. If the retry buffer entry 
is not available to receive a packet from the packet construction 

20 buffers 15O, or the number of packets awaiting transmission exceeds the 
size of the window, then the transfer and transmission is not 
performed. In this case, further requests to add message records are 
. reject eii^ , iinxil ..space ..becoip^s ..Bv.ajJ,abl.e.. J.f. a p.acicet . .±s .not. 
acknowledged within an acknowledgement timeout period, the packet is 

25 re-sent. 

In this embodiment, the construction buffers 252, 25^* 256 and 
258 become full when they contain eighty-six 1 byte records, forty- 
three 4 byte records, fourteen I6 byte records or one 256 byte record. 

The RLT protocol, which was introduced in the description of 
30 Figure 10 will now be described in more detail. 

The RLT protocol is used for passing control and data information 
via the control 212 and data 213 buses on the modem shelf and is valid 
on the radio link from the antenna 52 of the central terminal and the 
subscriber terminal (s) 20. 
35 The RLT protocol is an unbalanced protocol with the master 

communications interface 73 in the shelf controller 72 acting as a 
busmaster (M) and the slave communications interfaces 69. 71 and 75 on 



BNSOOaD: <QB__2301762A_JL> 



10 



29 

the analogue card, the modem cards and the tributary unit acting as 
slaves. In a preferred embodiment the master communications processing 
functions in the shelf controller are shared between a 68OOO series 
microprocessor, which will hereafter be referred to as the master 
client, and a Hitachi H8 microcontroller, which will hereinafter be 
referred to as the master server. The slave communications processing 
functions in the tributary unit are similarly shared between a 68OOO 
series microprocessor and a Hitachi H8 microcontroller. In the other 
slave units, the slave communications processing functions are 
performed in a Hitachi H8 microcontroller, which will hereinafter be 
referred to as the slave server. 

The second protocol is based on three layers. Figure 14 is a 
schematic representation of this layered protocol structure. 

The master communications end point functions performed at the 
15 third layer include the following functions. 

- A master initialisation service process (M-INIT) sets up the master 
client part of the master communications end-point in the shelf 
controller. This service call must be executed before the other 
communications functions can be performed. 

20 - A master initialisation poll process (M-POLL) initialises the master 
server part of the master communications end-point. This service 
process must be called before the following functions can be performed. 

- A master establish process (M-EST) establishes a .connectaon over, the 
bus from the master to a slave in response to a slave address 

25 referencing a slave board. Messages can be sent and received once a 
connection has been established. 

- A master send process (M-SEND) takes a message and sends it to a 
nominated slave over - the bus as long as the connection to the slave has 
already been established. 

30 - A master receive process (M-REC> receives a message from a slave to 
be passed, for example, to a management processor. 

- A master release process (M-REL) releases a connection to a nominated 
slave preventing further send and receive functions from being 
performed. 

35 - A master select process (M-SEL) provides an addressing mechanism for 
the master to select one of the slaves with which to communicate. 

The slave communications end-point functions performed at the 
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third layer include the following functions. 

- A slave initialisation service process (S-INIT) initialises the slave 
communications end-point. This service function must be called before 
any of the other functions can be performed. 

5 - A slave send process (S-SEND) takes a message and sends it to the 
master, as long as the master has already established a connection to 
the slave. 

- A slave receive process (S-REC ) function receives a message from the 
master to be passed, for example, to a network service element 

10 addressed by the message. 

The master communications end-point M includes the following 
f unc tional components . 

- A master VM component (MVM) provides a set of services for the 
management of storage to dynamically allocate memory for buffers, 

15 queues, semaphores and timers. 

- A master layer 1 component (MLl) provides low level communication 
primitives for supporting byte transfer from the master server using a 
serial communication interface. 

- A master status list component (MSL) holds the status of each link 
20 from the master to one of the slaves. This is updated when a 

connection is made, broken or released. 

- A master retry count component (MRC) tracks the number of retires 

. ':(?^t:tie.77nt;e.d «in,iinai?.te.r .Xc.^T.ila'ij^e ,.]-awa.r...2..rjarn:nMDi:r:'n^ ,J f ^jt:bji'f7 ,..fi*n*.c,j^f*::^r: 

the limits for layer 2, the master breaks the connection with the 
25 slave. 

The slave communications end-point M includes substantially the 
same functional components as the master. 

The master layer 1 component (MLl) provides the following level 
1 functions. 

30 - A master layer 1 initialisation process initialises the layer 1 
communications system. No layer 1 communications can take place until 
this process has been invoked. 

- A master layer 1 byte-output process outputs a byte out of a serial 
communications port and waits for an acknowledgement from the receiver. 

35 no acknowledgement is forthcoming, then a failure is registered. 

- A master layer 1 data-out process is similar to the byte output 
process except that more than one byte can be transferred. 
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- A master layer 1 address-out process is similar to the byte output 
process except that the source byte is output with a bit set to 
indicate that this relates to a multiprocessor address rather than a 
data byte. 

5 - A master layer 1 data-in process waits for a specified number of 
bytes to be received on the communications port. If less than the 
required number of bytes is received, then a failure is registered. 

The master VM component (MVM) provides the following functions:- 

- A master VM initialisation process initialises the master VM 
10 component. This must be called before any other VM service. 

- A master VM get-message process removes a message from one of the 
queues held by the VM component. 

- A master VM put-message process places a message on one of the queues 
held by the VM component. 

15 - A master VM queue-full process indicates whether a selected queue is 
full. 

- A master VM get-buffer process allows a buffer to be requested from 
a buffer pool held by the VM component. 

- A master VM give-buffer process allows a buffer requested by the get- 
20 buffer process to be returned to the pool. 

- A master VM get-semaphore process allows a semaphore held by the VM 
component to be set. 

- A master VM give-semaphore , process aJ.low.s,a semaphore .set .b^y thje ;gi?.t- 
semaphore process to be cleared. 

25 - A master VM set-timer process sets a time-out period for one of the 
timers held by the master VM component. A flag is set by the master VM 
component when the timer expires. 

- A master VM add-timer function process registers an application 
function with the master VM component to be called at a particular 

30 time. 

The master and the slaves both use VM components to provide 
buffers, queues, semaphores and timers in order to permit the transfer 
of messages. The operation of the second protocol will be illustrated 
by reference to specific examples below: 
35 The first example relates to the establishment of a connection 

from a master to a slave. 

To connect the shelf controller master to one of the slaves, the 
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shelf controller invokes the master establish process in the master 
end-point and supplies the link address of the slave (S-ID) with which 
the connection should be made. Figure 15 illustrates how the master 
300 maintains a message queue 302 to store requests such as an 
5 establish request, and how these requests are handled. 

Invoking the master establish process has the effect of placing 
a connect tag 30^ onto the message queue along with the address (S-ID) 
305 of the slave with which the connection is to be made. The work 
queue is shared between the client and server portions of the master 

10 end-point allowing a master client application to place a connect tag 
onto the message queue via the establish process and the master server 
to remove it and act upon it as part of the server poll processes. 
With this mixed client and server implementation, poll processes are 
introduced between the master and slave as set out below: 

15 - A master poll process 3O6 is provided in the master server and is 
called repeatedly on the master server. This services all of the 
requests placed in the message queue by the client. 

- A slave poll process 310 is provided in the slave server and 

similarly is called repeatedly on the slave server. 
20 When called, the master poll process checks the message queue for 

requests and in this case extracts a connect tag and the slave address 

from it. The pool process then sends out a connect command 308 to the 

nominatexl .slave .and. ;awa.l.t.s . a . reSiP,ons.e . .If thB, .T2.e.B^ans.e Xs...i;:aJ-ijd„ . x.hf?. 

status of the link to the selected slave is changed to 'connected', 
25 allowing the send and retrieve services to be used. 

The second example relates to the sending of a message from the 

master to a nominated and connected slave. This is illustrated in 

Figure I6. 

In order to send a message from the master to the nominated and 
30 connected slave, an application invokes the master send process 312. 
The send process requests a buffer 323 from the master VM component 
buffers 32^ and copies the message to be' sent to it. It then places a 
send tag 316 and the buffer number 318 on the work queue 31^ for a 
subsequent poll call to deal with. 
35 The master poll process 3O6 extracts the send tag 316 and the 

buffer number 318 from the message queue 31^^. It uses the buffer 
number 3:8 to extract 326 the message from the buffer 323 and then 
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sends 330 the message to the nominated slave. 

The message is received at the slave end-point under interrupt. 
At the next call to the slave poll process 310, a buffer 3^3 is 
requested from the slave VM component buffers 34^ to hold the incoming 
5 message. The slave poll process 310 then places the message into the 
buffer 3^3 and puts a receive tag 336 and the buffer number 338 onto 
the slave receive queue 33^- Messages can be received and put into the 
slave receive queue 33^ until either the queue is full or no further 
buffers are available in the slave VM component buffers 344. Once a 

10 message has been transmitted and successfully received, the master 
gives its message buffer back to the master VM component for re-use 
using the master give-buffer process. 

The message is delivered to the application when the application 
invokes a slave receive process 346. The receive process 346 checks 

15 the receive queue 334 for entries and, on finding one, extracts the 
buffer number 338 and reads the incoming message from the buffer 343. 
The buffer 343 is then returned to the slave VM component for re-use. 
The sequence for sending a message from the slave to the master 
is similar except that the slave holds a separate send queue, rather 

20 than placing send and receive tags on the message queue. Send requests 
are placed on the send queue by client calls to the slave send process. 
When a slave receives a ready- to-receive command from the master, the 
sl.ave poJ..^ .process :remoues..xi?i jsj^xxt^ .re^Que^at-^x^ -i:j7,aTj ..i-.-h?: 

send queue, gets the message from the slave VM buffer and transmits it 

25 to the master. At the end of the sequence it returns the buffer to the 
slave VM component for reuse. 

The second protocol uses a sequence number, which 
alternates between 1 and 0, for passing messages between the master and 
the slave. An example of a message exchange is set out below. 

30 

Initially an exchange between the master and the slave establishes a 
link as part of a level 2 process. 
Master Slave 
Poll (address) 

35 <-- Response (data or not) 

Reset 

Reset response 
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Then a data message exchange taJces place as part of a level 1 process . 
Master Slave 
SE:ND(0) data 

<— SRR(l) 
MRR(O) — > 

DATA(l) 

In this process the 1 or 0 between brackets associated with each 
message forms the sequence number, which can be represented by a single 
bit which is switched by a recipient of a message before a reply is. 
sent in response to the successful receipt of the message. If the 
message is not received correctly, then the sequence number is not 
switched. This is illustrated in the following example. 

Master Slave 
SENDfO) data --> 

<-- SRR{1) 
MRR ( 1 ) - - > 

20 <-- SRR(O) 

MRR(l) 

<-- DATA(O) 

In the sequence shown immediately above. the SRR message 
25 transmitted by the slave was not correctly received by the master. 

Accordingly, a response was sent without changing the sequence number. 

This then caused the slave to re-send the SRR message and the sequence 

proceeds as before but with the sequence numbers now inverted with 

respect to the first example. 
30 In practice the sequence number is provided twice in a message 

byte, in two bits, although it could alternatively be provided only 

once, in one bit. 

The shelf controller provides an interface between the SMP and 

RLT protocols. The shelf controller operates mainly in accordance with 
35 the first protocol, but is provided with the microprocessor and a 

communications microcontroller which together form a client/server end 

point for the second protocol and convert messages from one protocol to 
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the other. Fi^re l6 illustrates an example of how the shelf 
controller provides an interface between the messages sent in 
accordance with the two protocols, in this case for event handling. 

An event command interpreter ^Q2 decodes event commands received 
from the management processor under the SMP protocol and appropriate 
functions from other event modules are called to implement the command. 

An event message decoder decodes an incoming message received 
from one of the slave modules under the RLT protocol and calls 
appropriate functions from the event controller. 

An event processor ^406 provides one function for each event 
message type and, in addition, functions which service internal events 
from a configuration controller 408 and other sources such as a card 
presence detector ^09 and a state machine controller 410 in the shelf 
controller. The functions include passing events to either a non- 
15 urgent buffer ^411 or to an urgent buffer ^12 and directing movement of 
buffer contents to and from the management processor in response to 
control messages . 

An event composer 4l4 allows the constructions of messages for 
sending under the SMP protocol containing event records and other 
20 related matters. 

An event time administrator kl6 marks the events with the time 
they are received by the event processor. A sequence number 
administrator 4l8 handles the .as.slg;am.er;it .of .:S.f^aueace aumhers .^o e.v:en\.t 
messages. A separate current sequence number is maintained for each 
25 event. 

Similar processing is performed for alarms and other messages. 
Figure l8 is a schematic overview of the site controller and 
illustrates the relationship between various server objects. The 
management of the telecommunications network including the central 
30 terminal, the subscriber terminals and the site controller, is based on 
a hierarchical object-based data structure. Figure 19 provides one 
possible overview of that data structure. 

The SMP communications handler 512 is responsible for the 
transmission and reception of SMP messages between the site controller 
35 and the shelf controller. A test manager 51^ carries out line tests. 
A site viewer 5l6 enables a view to be created of the whole site using 
data contained in the site configuration database which is managed by 
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the site configuration database manager 5O8. 

The site configuration database contains an object-based 
structure where a plurality of objects, each representing a respective 
element of the site, are arranged in a structured hierarchy. Figure 18 
5 represents an example of such a structured data base. The various 
objects in the list are linked together by at least one pointer for 
each node which points to its parent object. This process continues 
right up to the root node which represents the whole site. 

Various objects will be described in more detail below. Each of 

10 the objects includes a name field defining the name of the object and 
a status field containing status information about the object. The 
object may also contain one or more alarm parameters which can be set 
in response to specific alarm conditions relating, for example, to 
hardware errors, line malfunctions etc. The status field for an object 

15 includes a fault parameter which becomes set when at least one alarm 
parameter in the object or in a dependent object is set. In other 
words, when a fault parameter is set in one object, this fault status 
is propagated up the tree using the pointers to successive parent 
objects. Each of the objects also contains a definition of the object 

20 which can be used for displaying a representation, or view, of that 
object . 

There is one site object (SITE) 530 in a database. This contains 
-.ri^a^ta .aho.hvt. ithe^,s.r.te .and ..i-s- .created ^\JtQmat.i.cally ,twhien . the. ,d.a.tab,5.s-e ,-"i.s 
initialised. As well as a name field and a status field, this object 
25 contains a field defining the site location and a list of rack objects 
that the site contains. 

The Rack objects (RACK) 532, 5UO. 5^2, etc. each represent a rack 
and contain data about the rack including a name field, a status field, 
a pointer to the site object 530, and pointers to the shelf objects 
30 (e.g., for rack object 532, pointers to the combiner shelf object (CS) 
53^ and up to four modem shelves (MS) 536. 538)- 

The combiner shelf object (CS) 5^0 represents an RF combiner 
. shelf and contains data about the combiner shelf including a name 
field, a status field, a pointer to the containing rack object (e.g., 
35 RACK 532). a pointer to the shelf's low noise amplifier card object 
(LNA) 536* and pointers to power amplifier card objects (PA) 538. 

The modem shelf objects (MS) 536 and 538 each represent a modem 
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shelf and contain data about the modem shelf including a name field, a 
status field, a pointer to the containing rack object (e.g., FIACK 532), 
an identifier field for the position of the shelf in the rack, a field 
for the identity of the serial port through which the site controller 
5 communicates with the shelf, a field for the baud. rate for the serial 
port, a pointer to the shelf controller card object (SC) 5^0, a pointer 
to a tributary card object (TU) 5U2, a pointer to the RF analogue card 
object (RFA) 54^, and pointers to up to eight modem card objects (MC) 
5^6. 

10 The modem card objects (MC) 5^6 each represent a modem card and 

contain data about the card including a name field, a status field, a 
pointer to the modem shelf object (e.g., MS 536) containing the modem 
card, cin identifier number for the modem card (0-7) and pointers to 
modem objects (MODEM) 550. 

^5 The modem objects (MODEM) 550 each represent a modem and contain 

data about the modem including a name field, a status field, a pointer 
to the modem shelf object (e.g.. MS 536), a pointer to the subscriber 
terminal object (ST) 552 which is connected via the radio link to the 
modem, pointers to subscriber objects (SUB) 55^ supported by the modem 

20 and pointers to the tributary unit channel objects (TUCH) 5^8 which 
connect to the modem. 

The shelf controller card object (SC) 5^0 represents a shelf 
controller and contains data about the card including , a name field, a 
status field and a pointer to the modem shelf object (e.g., MS 536). 

25 The Tributary unit card (TU) 5^2 represents a tributary card and 

contains data about the card including a name field, a status field, a 
pointer to the modem shelf object (e.g.. MS 536), pointers to the 
card's tributary unit channels (TUCH) 5^8 and a definition field for 
the protocol used by the tributary card. 

30 The RF combiner and analogue card object (RFA) 544 represents the 

RF card and analogue card pair and contains data about the card pair 
including a name field, a status field, a pointer to the modem shelf 
object (e.g.. MS 536), a field representing the transmitter frequency 
and a field representing the receiver frequency. 

35 The low noise amplifier card object (LNA) 536 represents a RF 

combiner shelf low noise amplifier card and contains data about the 
card including a name field, a status field and a pointer to the RF 
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combiner shelf object (RFC) 53^. 

The power amplifier card objects (PA) 538 each represent an RF 
combiner shelf low noise amplifier card and contain data about the card 
including a name field, a status field and a pointer to the RF combiner 
5 shelf object (RFC) 53^. 

The subscriber terminal object (ST) 552 represents a subscriber 
terminal served by a modem and includes data about the subscriber 
terminal including a name field, a status field, the CDMA code of the 
subscriber terminal channel and a pointer to the corresponding modem 
10 (MODEM) 550. 

The subscriber objects (SUB) 55^ each represent a subscriber 
circuit and contain data about the subscriber including a name field, 
a status field, a recall field, an intrusion tone field and a 
subscriber line active field as well as a pointer to the modem (MODEM) 
15 550 and the tributary unit channel (TUCH) 5^8 associated therewith. 

A line test object (LT) 556 represents a line test in progress 
and contains data about the line test including a name field, a status 
field and a pointer to the subscriber object 55^. 

A test result object (TR) 558 indicates a test result and 
20 contains data about the test result including a name field, a status 
field arid a pointer to the line test object which initiated the test. 
Uncleared alarm objects 559 are chained to their source card. 

-He.mnniJijE: ..to .Fi;(r?.ir*» IR .t-he ..t.r.anrM?tcr..inn. Jiae >3naR<i'fr,e.r .hvLO .ecan.tai in ^; 

a history of all the configuration messages sent to the site's shelves 
25 and all the event and performance messages received from the shelves, 
subject to log file size limits. 

The site viewer 516 allows an operator to monitor the state of 
the site. The site viewer provides alternative views of the site to be 
displayed on the display screen of the site controller workstation 
30 using the data stored in the object database. 

In accordance with a first view, the site viewer provides a view 
showing the main nodes of the object based hierarchy, namely a 
representation of the site object node with a representation of each of 
the rack object nodes connected thereto and the links between them, 
35 corresponding to the pointers in the objects. The display can be 
structured similarly to the representation in Figure 19. but without 
the lower order objects being displayed. 
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The user can interact with this first view, for example to expand 
one branch of the view. This can be achieved using conventional 
windows-based operating tools for pointing to and selecting an 
displayed object using a mouse and mouse buttons, for example. The 
5 daughter nodes for a selected node can then be displayed. This process 
can be used, for example, to expand branches of a tree to locate 
faults. 

The site configuration database manager interacts with the object 
database to monitor and update fault parameters and alarm parameters in 

10 the database objects. When an alarm condition occurs in a network 
element, the database manager sets the corresponding alarm parameter in 
the object for that network element. At the same time the fault 
parameter is set for that database object. A database object may 
contain more than one alarm parameter. The fault parameter in the 

15 object database status field is set whenever one or more alarm 
parameters are set in that database object. The database manager also 
traces the pointers up the tree to the site object setting the fault 
parameters for each of the database objects which it encounters on the 
way . 

20 The site viewer, and also the other viewers to be described 

later, are responsive to the fault parameters in the database objects 
to visually distinguish displayed objects for which a fault parameter 

the displayed colour of the object in question, and/or by causing the 
25 object in question to flash. In a preferred embodiment, a displayed 
object for which a fault condition has occurred is flashed red. 

In the situation where the first site view mentioned above is 
displayed, the site object and the rack object corresponding to the 
rack in which a fault has occurred will flash red. This will alert the 
30 operator to the fault condition, and by selecting the appropriate 
displayed rack object, the database tree structure can be expanded 
along the appropriate branch down to the object corresponding to the 
network element where the fault has occurred. 

Alternative display expansion modes can be provided where the 
35 tree is automatically expanded when a fault occurs, or when the 
operator requests the expansion of the tree (for example by selecting 
the lowest order object currently displayed in the fault line) or where 
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the tree has to be expanded manually level by level by the operator 
selecting the appropriate object to be expanded. 

A second site view is also provided where a graphical 
representation of each rack on the site is displayed to the operator on 
the display of the site controller work station. Each rack object 
includes a rack identifier so that each displayed representation of a 
rack corresponds to a physical rack. The site viewer causes the 
objects for the racks to be accessed via the database manager 5O8 in 
order to display an appropriate graphical representation of each of the 
rack frames with openings for the rack shelves. These openings are 
then filled with representations of the fronts of the respective 
shelves. The site viewer causes the objects for the shelves to be 
accessed via the database manager 508 in order to display a graphical 
representation of each shelf front in an appropriate opening in the 
graphical representation of corresponding rack frame. The combiner 
shelf always occupies a fixed position within the rack and the modem 
shelf objects contain an identifier field for the position of the shelf 
in the rack, so that each representation of a shelf front in the rack 
display corresponds to a physical rack shelf position. 

In this case, when the fault parameter in a shelf object is set, 
the representation of the shelf on the display will be highlighted 
(e.g.. by displaying the shelf in a different colour or flashing), 
• A cco.rdlnie,.! . ^^.iLq,;xlty .....by ..u.lfi:fd.i;ifr ....t-hf? ..xlxGpA.n.\'... .y'^Jaf?. ,.i^ifp/=*r.n.-riCTT' ,^a^r 
immediately identify which rack has a shelf with a fault and the 
physical position of the shelf within the rack. 

Moreover, the site viewer is responsive to the operator selecting 
the highlighted shelf (eg by clicking on a mouse button when a mouse 
pointer is pointing at the shelf in question) to call the shelf viewer 
518. The shelf viewer 520 causes a graphical representation of the 
shelf of interest to be displayed on the workstation display; It does 
this by causing the object for the shelf concerned to be accessed via 
the database manager 508 to display an appropriate graphical 
representation of the shelf. Also, the shelf viewer causes the objects 
for the cards on the shelf to be accessed via the database manager 508 
to display a graphical representation of each card on the shelf. The 
card objects include data defining the object view and the position of 
the card within the shelf view. The shelf viewer is responsive to a 
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fault parameter being set in the object for a card on the shelf to 
highlight the graphical representation of that card. In this way the 
operator can readily identify the physical card in which an error has 
occurred . 

5 The shelf viewer is responsive to the operator selecting the 

highlighted card (eg by clicking on a mouse button when a mouse pointer 
is pointing at the card in question) to call the card viewer 520. The 
card viewer 518 causes a graphical representation of the card of 
interest to be displayed on the workstation display. It does this by 

10 causing the object for the card concerned to be accessed via the 
database manager 508 to display an appropriate graphical representation 
of the card. Also, the card viewer causes the objects for the network 
elements on the card to be accessed via the database manager 5O8 to 
display a graphical representation of each element on the card. The 

15 network element objects include data defining the object view and the 
position of the element on the card view. The card viewer is 
responsive to a fault parameter being set in the object for a network 
element on the card to highlight the graphical representation of that 
element. In this way the operator can readily identify the physical 

20 element in which an error has occurred. 

The subscriber viewer 522 extends this process to a view of the 
subscriber line and the subscriber terminal 20. 

It will be appreciated that the jaecb;anl;sm vdescrlbeid ..above 
provides an effective and user friendly arrangement for identifying 

25 faulty components or elements within a network. 

The updating of the fault parameters described above is performed 
by the site configuration database manager in response to alarm event 
messages received using the message structures described above from the 
physical elements at which faults have occurred. The alarm event 

30 messages are used to set alarm parameters in the lowest order objects 
associated with physical network elements. The establishment of alarm 
conditions (faults) can be achieved in any appropriate manner, either 
by commands sent out from the site controller or other control elements 
in the network at appropriate times to test for faults, or by the 

35 elements where a fault has occurred automatically reporting the faults 
to the site controller. 

An alarm viewer 524 enables alarm events occurring at a site to 
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be monitored on the display of the site controller work station. This 
provides a tabular display of all the events that have occurred in the 
system. One of the event entries in the tabular display will be 
highlighted by the alarm viewer to indicate the current event. The 
5 highlight can be moved through the use of cursor keys and/or mouse 
movements and clicks. 

A command history viewer 526 is used to display transaction 
history data retrieved from the database. A performance statistical 
viewer 528 similarly permits the display of statistical data. 
10 The site controller command structure described with reference to 

Figures l8 and 19 can be used for monitoring faults in a working 
network or for active control of the network. It can also be used as 
part of a simulator of part or all of the network for design and/or 
testing purposes. 

15 Figure 20 is a schematic representation of elements of a 

simulator 600 incorporating the control structure described with 
reference to Figure l8 and 19 can be switched into the X.25 connection 
57 between an element manager 58 and a shelf controller 72. The 
simulator 6OO can be implemented by means of a personal computer or 

20 workstation comprising a processor, memory, display, keyboard, etc., 
suitably programmed to implement the desired processing functions. 

As illustrated in Figure 20, the simulator 6OO includes an SMF 
..s»_tmi 1' iT^iriQ.r ££^2. ^hi -c h .ir,r.o.ui:des . ^.n^r^-mi ; J,(?.r..i lon . cf x,b . ^man.tJiPiTjTie txt. . ,D.r/:>.Cie 5r..s.o r 
(the site controller 56 or the element manager 58) and a shelf 

25 simulator 604 which simulates the operation of a modem shelf ^6. The 
SMP simulator can provide basic management processor functions for 
testing the SMP protocol only, but it could be expanded to provide a 
full emulation of the site controller. The shelf simulation includes a 
full emulation of the physical shelf controller using largely the same 

30 software as the physical shelf controller. It also provides a 
simulation of selected management functions of the network elements on 
the modem shelf which are connected to the shelf controller, to the 
extent that they are able to respond to commands from the shelf 
controller and to generate alarms and other status messages in response 

35 to being activated. In alternative embodiments a full simulation of 
the central station could be provided. 

The simulator includes em SMP interface 6O6, including the 
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modular message hamdling structure described with reference to Figure 
11 ♦ which enables a real management processor to interface with the 
simulator by providing an interface between serial communications and 
the simulator's internal representation of SMP messages. The simulator 
5 also includes a shelf interface 608, including the modular message 
handling structure described with reference to Figure 11 » which enables 
the simulator to interface with a real shelf via RS232 port. 

The simulation of each of the various elements described above is 
embodied in objects which define those elements, each object containing 
10 a functional emulation of the element concerned. 

An SMP exerciser 6lO permits a user to construct low level SMP 
messages for testing the shelf controller on a message by message 
basis . 

The protocol monitor 6l2 provides a monitor function for SMP 
15 messages as they pass between the other parts of the system. Thus 
messages are passed via the monitor with the monitor providing the 
necessary routing functions, allowing messages to be displayed, stored 
and stepped through and otherwise keep track of the messages being 
sent. As such, the simulator provides a powerful diagnostic tool for 
20 the telecommunications network. 

Although a particular embodiment has been described herein, it 
will be appreciated that the invention is not limited thereto and that 
m<aav modifications .and ..addict J-onf? ...the.ne.t;o*:jFL».' ±ie .,ma-die ^wlitahijn .x.hif; .s-.capr^ 
of the invention. 
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CLAIMS 

1. A message packet transmitter for generating message packets for 
passing control information between a central telecommunications 

5 station and a controller for one or more telecommunications stations, 
wherein said message packet transmitter generates packets of 
information comprising: 

a packet header including a packet start pattern and a message 
size identifier for individually setting a message size for respective 
10 packets; 

a variable number of message records, each having a size 
determined by the message size selected for the packet; and 

a packet terminator including a packet end pattern invalid as an 
initial bit sequence for a message record, 

15 

2. A message packet transmitter according to claim 1, wherein said 
message size for said message packets is selectable from a 
predetermined plurality of fixed sizes. 

20 3. A message packet transmitter according to claim 1 or claim 2, 
wherein said message records in said message packet comprise a fixed 
length message record header and a message field for a said message, 

-j=;.t?.:Ld cnes.sa/?:e ^fie.Ld .haA^j ne a .si-z.e co.r.Tr.espionri.i.n-fr xo ..Sia.ld - xnes^sair-^ .si. re. 

25 ^. A message packet transmitter according to claim 1 or claim 2 
wherein said message records in said message packet comprises a message 
record header and a message field for a said message, said message 
record having a size corresponding to said message size. 

30 5- A message packet transmitter according to any one of the 
preceding claims, wherein a said message record is provided w^ith a 
message control field including a message type identifer identifying 
said message record as a command message or a report message and/or an 
element address to which said message record refers. 

35 

6. A message packet transmitter according to any one of the 
preceding claims, wherein a said message record is provided with a 
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message identifier field for defining a function code for said message 
record. 

7. A message packet transmitter according to any one of the 
5 preceding claims, wherein a said message packet is provided with a task 

identifier for associating message records. 

8. A message packet transmitter according to any one of the 
preceding claims, for supplying a message packet sequence identifier to 

. 10 said packet header of each message packet. 

9. A message packet transmitter according to claim 8 wherein said 
message packet sequence identifier is a number which is incremented 
modulo-n. where n is a whole number greater than 0, for successive 

15 packets. 

10. A message packet for passing control information between a 
central telecommunications station and a controller for one or more 
telecommunications stations » wherein said message packet comprises: 

20 a packet header including a packet start pattern and a message 

size identifier for individually setting a message size for respective 
packets ; 

a variable number of message records, each having ..a size 
determined by the message size selected for the packet; and 
25 a packet terminator including a packet end pattern invalid as an 

initial bit sequence for a message record, 

11. A message packet according to claim 10, wherein a said message 
record includes a fixed size message header and a message field having 

30 one of a plurality of selectable sizes. 

12. A message packet according to claim 10 or claim 11 wherein each 
message record includes header fields comprising: 

a message control field including a message type identifier 
35 identifying said message record as a command message or a report 
message and an element address to which said message record refers; 

a message identifier field for defining a function code for said 
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message record; atnd 

a task identifier for associating message records. 

13. A message packet according to any one of claims 10 to 12. wherein 
5 said message packet header includes a message packet sequence 
identifier. 

1^. A message packet receiver for receiving message packets 
according to any one of claims 10 to 13 or for receiving message 

10 packets from a message packet transmitter according to any one of 
claims 1 to 9 , wherein said message packet receiver comprises -means 
responsive to said start pattern to identify a message packet header, 
means for extracting said message record size identifier for said 
message packet header and for .receiving and routing said message 

15 records until said end pattern is recognised. 

15. A message packet receiver for receiving message packets according 
to 13 or for receiving message packets from a message packet 
transmitter according to claim 9» wherein said message packet receiver, 
20 on successful receipt of a message packet, returns to the message 
packet generator an acknowledgement including the packet sequence 
number of the message packet successfully received. 

16- A message packet receiver for a message packet system for passing 
25 control information between a central telecommunications station and a 
controller for one or more telecommunications stations in which a 
message packet transmitter is arranged to allocate message packet 
sequence identifiers to successive message packets with said message 
packet sequence identifier being changed in accordance with a 
30 predetermined sequence for successive message packets, said message 
packet receiver being arranged to track the message packet sequence 
identifiers for successive packets and to return an acknowledgement 
including the message packet sequence identifier for the last 
successf ull\* received message packet when said predetermined sequence 
35 is broken or after a predetermined number of successfully received 
messages since the last acknowledgement was sent, said predetermined 
number defining a sequence window. 
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17- A message packet receiver according to claim l6> wherein said 
message packet receiver is responsive to receipt of a message packet 
with a message sequence identifier for a previous sequence window which 
an acknowledgement has already been sent to retransmit said 
5 acknowledgement for said previous window. 

l8. A message packet receiver according to claim l8» wherein said 
message packet receiver is responsive to receipt of a message packet 
having a message packet sequence identifier which is out of sequence 
10 but does not relate to said previous sequence window or to a next 
sequence window to discard said message packet. 

19- A message packet receiver according to any one of claims l6 to l8 
wherein said message packet sequence identifier is a number which is 
15 incremented modulo-n, where n is a whole number greater than 0, for 
successive packets. 

20. A message packet transmitter for passing control information 
between a central telecommunications station and a controller for one 

20 or more telecommunications stations, said message packet transmitter 
being arranged to allocate message packet sequence identifiers to 
successive message packets, with said message packet sequence 
.identifi-'er beln^g chai.ged In .-accordance with .r.a .p.nedeteriD±nsed sequence 
for successive message packets, and to transmit up to a predetermined 

25 number of message packets to a message packet receiver, said 
predetermined number defining a sequence window, said message packet 
transmitter being responsive to the receipt of an acknowledgement 
including a message sequence identifier associated with message packet 
within said sequence window other that the last message packet of said 

30 window and to the absence of receipt of an acknowledgement from said 
message packet receiver including the sequence identifier for the last 
message packet of said window within a predetermined period following 
the trainsmission of the last of message packet of said sequence window 
and to retransmit the message packets subsequent to said message packet 

35 associated with message sequence identifier in the received 
acknowledgement . 
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21. A message packet transmitter according to claim 20, wherein said 
message packet transmitter is responsive to the absence of any 
acknowledgement from said message packet receiver within a 
predetermined period following the transmission of the last of message 

5 packet of said sequence window to retransmit all the message packets of 
said sequence window. 

22. A message packet transmitter according to claims 20 or 21 wherein 
said message packet sequence identifier is a number which is 

10 incremented raodulo-n, where n is a whole number greater than 0, for 
successive packets. 

23- A message packet system comprising a message packet receiver 
according to any one of claims l6 to 19 and a message packet 
15 transmitter corresponding to claim 20 or claim 21. 

24. A controller for one or more central telecommunications stations, 
said controller comprising a message packet transmitter according to 
any one of claims 1 to 9 . 20 and 21 for transmitting control 

20 information to a central telecommunications station and/or a message 
packet receiver according to any one of claims 14 to. 19 for receiving 
control information from a central telecommunications station. 

25. A central telecommunications station comprising a message packet 
25 receiver according to any one of claims l4 to 19 for receiving control 

information from a controller for one or more central 
telecommunications stations and/or a message packet transmitter 
according to any one of claims 1 to 9 . 20 and 21 for transmitting 
control information to a controller for one or more central 
30 telecommunications stations. 

26. A telecommunications system comprising a controller according to 
claim 24 and one or more central telecommunications station according 
to claim 25. 

35 

27. A message packet transmitter substantially as hereinbefore 
described with reference to the accompanying drawings. 
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28. A message packet substantially as hereinbefore described with 
reference to the accompanying drawings. 

29- A message packet receiver substantially as hereinbefore 
5 described with reference to the accompanying drawings. 

30. A message packet system substantially as hereinbefore described 
with reference to the accompanying drawings. 

10 31- A controller for one or more central telecommunications stations 
substantially as hereinbefore described with reference to the 
accompanying drawings. 

32. A central telecommunications station substantially as 
15 hereinbefore described with reference to the accompanying drawings. 
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